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Remarks 

The amendments to the claims 

Examiner will immediately see that the amendments are fully supported by the 
Specification as filed and that the amendments to the second clause of the body of claim 
5 187 and the related amendments to the dependent claims overcome the rejection under 35 
U.S.C. 112, second paragraph. The amendments to the first clause of the body of claim 
187 make it clear that a representation of a model entity is capable of simultaneously 
belonging to two hierarchies. 

10 Patentability of Applicant's amended claims over the Board and Aoyama references 

This traversal will begin with a review of the state of the art at the time Applicant's 
invention was made, will then present the invention, will next discuss the disclosure of 
Aoyama, and finally show why Applicant's claims are patentable over the Board and 
Aoyama references. 

15 

State of the art at the time Applicant 's invention was made 

The problem that motivates people to build interactive project management systems is the 
difficulty of understanding what is going on in an organization. The systems work by 
providing tools for making a model of the organization which users of the system may 

20 then view and manipulate. The model is generally implemented using a relational 
database. One approach, used in systems such as the ones described in the Board, is to 
provide a single class of model into which all kinds of organizations must be made to fit. 
Organizations are typically hierarchically organized, and consequently, some of the 
systems permit hierarchical organization of at least some aspects of the model. One of 

25 these is Open Plan as disclosed in Board. Common to all of the interactive project 
management systems is the problem that if an aspect of an organization does not fit the 
class of model provided by the project management system, it cannot be expressed in the 
project management system. 

30 U.S. patent 5,655,1 18, Heindel, et al., Methods and apparatus for managing information 
on activities of an enterprise, issued 8/5/97 (henceforth "Heindel"), cited in the Office 
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action of 5/27/04, solves the problem of aspects of an organization that do not fit the class 

of model provided by a particular project management system by permitting the user to 

make any kind of model he or she wants of the organization. As shown in Heindel's 

FIG. 2, a model made using Heindel's system may be made up of strategic plans, 

5 projects, tasks, products, subprojects, or employees, and any of these elements may be 

related to any other of these elements. As set forth at col. 6, lines 62-65 of Heindel, 

activity information data elements are stored in the database 200 using a 
non-hierarchical entity relationship model, as opposed to the hierarchical 
models employed by conventional project management systems. 

10 

FIG. 5 gives an example of the kinds of models that can be made usmg the system of 
Heindel. 

Heindel's system overcomes the limitations of the project planning software such as 
1 5 Open Plan that provides a single class of model, but it does so at a cost: 

• Because the user can make any kind of model, it is left to the user to decide in every 
respect how the organization should be modeled. In effect, every user who employs 
Heindel to model an organization must "reinvent the wheel". 

• Because the models made using Heindel's system may be completely arbiti-ary, they 
20 will be difficult for users other than the creator of the model to understand. 

• The generality of the system requires a high degree of complexity in the database 
itself and in the user interface and report generation systems. 

The problem posed to the user by systems that have a single class of model on the one 
hand and Heindel's system on the other is this: The systems that permit a single class of 

25 model are easy to understand and use, but are not powerfiil enough to model many 
commonly-occurring aspects of organizations. For example, the single model class 
systems cannot easily deal with cross-hierarchical organizational functions such as HR or 
accounting or cross-hierarchical matters such as customer satisfaction. Heindel, on the 
other hand, can model anything, but each modeUng problem must be approached from 

30 scratch and neither model makers nor model users can use experience gained with one 
model made using Heindel's system to understand another model made using Heindel's 
system. 
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Applicant's invention of claim 187 

Applicant's "system for supporting management of a business by people involved 
therein" solves the problem posed by the limitations of the single model class systems 
5 and the complete generality of Heindel by providing users with tools that let them model 
their organization as it appears from two hierarchical perspectives. The first of these 
perspectives is a hierarchy of goals, which is similar to a hierarchy which a user may 
make with a planning tool such as Open Plan. The second of these is a hierarchy of 
domains, that is, elements of the business organization which cut across the hierarchy of 

10 goals. An element of the goal hierarchy may also belong to a domain in the hierarchy of 
domains. FIG. 8 shows a typical domain hierarchy; as can be seen from the figure, the 
domains are business concerns which cut across many goals. The goal hierarchy is 
described at least at page 22, line 19-page 23, line 7 of Applicant's Specification and 
shown in FIGs. 13-15. FIG. 16, finally shows how the goals in the goal hierarchy may be 

15 sorted by the domain hierarchy, so that a user of the system can see the goals in the 
context of the domain hierarchy. The GUI shown in FIGS. 8, 13-15, and 16 permits the 
user to define and modify the goal hierarchy and the domain hierarchy, define and 
modify goals and position them in the goal and domain hierarchies, and access 
information such as documents, discussions, and email about a goal via the representation 

20 of the goal in the GUI. 

By adding the domain hierarchy to the goal hierarchy and permitting elements of the goal 
hierarchy to be related to elements of the domain hierarchy, Applicant's management 
support system permits models which provide perspectives lacking in the simple models 

25 permitted by the Board systems while avoiding the complexities of Heindel's generalized 
modeling system. Both the goal hierarchy and the domain hierarchy are intuitive in 
themselves, and the manner in which an element of a domain hierarchy may also relate to 
a domain in the domain hierarchy is also easy to understand. Further, since all models 
made using Applicant's modeling system have the same characteristics, model makers do 

30 not have to constantly "reinvent the wheel" and users who encounter new models made 
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using Applicant's modeling system already have the knowledge needed to understand the 
models' basic structures. 

The disclosure of Aoyama 
5 Applicant's invention, Heindel, and the systems disclosed in Board all permit their users 
to make their own models of what they are doing within the class of models permitted by 
the system they are using. Aoyama, by contrast, is not a system for making, modifying, 
and using a model, but instead a software development envirormient which implements a 
particular model of the software development process. The users of Aoyama cannot 
10 change the model upon which the software development environment is based in any 
way. 

The foregoing distinction between a system which implements a model and the system of 
Applicant's invention, the system of Heindel, and the systems disclosed in Board, which 

15 are systems for making and modifying models, is apparent on careful consideration of the 
figures of Aoyama. FIG. 1 shows how the Agile Software Process (ASP) software 
development process that Aoyama' s software development environment was developed 
to support. FIG. 2, which Examiner chiefly relies on for her rejections, shows how the 
ASP is managed in terms of the categories organization, process, and project. It is this 

20 management model which is implemented in Aoyama' s software development 
environment. FIGs. 3-5 and 8 show various aspects of the architecture of the software 
development environment. FIG. 6 shows the workflow in the software development 
environment. Fig. 8 shows a report generated by the environment; FIG. 9 is a 
categorization of design information. The only disclosure of how the user relates to the 

25 software development system is provided by FIGs. 7 and 11, which show the GUIs for 

the Prime and WAIN levels of the software development system. FIG. 7 is described as 

follows at page 62, first column, begirming at line 7: 

Figure 7 shows a screen view of Prime. The upper-left subwindow shows 
a list of base processes. The upper-right subwindow shows planning 
30 support. The progress of multiple teams and individual developers appear 

in the screen's left and right-bottom subwindows, respectively. 
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FIG. 1 1 is described only as a "Sample screen from WAIN". Neither GUI suggests in 
any way that the user of the software development system can alter the software 
development management model of FIG. 2. 

5 This distinction between a system which implements a model and a system which permits 
users to make models becomes particularly apparent when the GUI of FIG. 7 is compared 
with the GUIs of Apphcant's FIGs. 6, 12, and 13, which show how users of Applicant's 
system may make and modify their models' hierarchies. 

10 Patentability of claim 187 over the combination of Board and Aoyama 
As currently amended, claim 187 reads as follows: 

187, (currently amended) A system for supporting management of a 
business by persons involved therein, 
the system comprising: 

15 a processor which has access to a representation of a 

model of the business, the model including representations of model 
entities, a given representation of a model entity being capable of 
simultaneously belonging to hierarchies including a hierarchy and another 
hierarchy, and the representations of model entities providing access to 

20 information relating to the business; and 

an interface to the system for a person of the persons, the 
interface being provided by the processor and the interface receiving first 
inputs from the person, the processor responding to the first inputs by 
outputting the representations of the model entities, of the hierarchies, 

25 and/or of the information to which the model entities provide access in 

tangible form and further receiving second inputs from the person to 
which the processor responds by modifying the representations of the 
model entities, the hierarchies, and/or the information to which the 
representations of the model entities provide access. 

30 

Examiner bases her rejection of the claim on the combination of Board with the 
disclosure of FIG. 2 of Aoyama. As already pointed out, what FIG. 2 shows is not a 
model which users of Aoyama' s software development environment may view and 
modify, but rather a "management model" which the software development environment 
35 "supports" (Aoyama, page 59, col. 1, lines 34-35. Because the "management model" of 
FIG. 2 has nothing whatever to do with any model which may be viewed and modified in 
Aoyama, FIG. 2, and indeed all of Aoyama, are simply not relevant to the invention of 
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claim 187 and cannot supply the claim limitations that are lacking in Board. Since that is 
the case, the combined references do not disclose all of the limitations of claim 187 and 
Examiner has not made her prima facie case of obviousness. As Examiner will 
immediately see, the same arguments hold with regard to independent claim 198 as well. 
5 Further, because Aoyama is not relevant to Applicants' invention, dependent claims 188, 
192-196, and the corresponding claims dependent from independent claim 198 are 
patentable in their own rights over the Board reference for the reasons set forth in 
AppUcant's response of 2/24/05. 

10 Conclusion 

Applicants have amended their claims as requested by Examiner to make it clear that a 
representation of a model entity is capable of simultaneously belonging to more than one 
hierarchy, have amended claim 187 and dependent claims 188, 190, 191, 192, and 193 to 
overcome the rejection under 35 U.S.C. 112, and have shown that the combination of the 

15 Board and Aoyama references does not show all of the limitations of Applicants' 
independent claims and that certain of the dependent claims are patentable in their own 
rights over the references. Applicant has thus been fully responsive to Examiner's Office 
action of 12/13/05 as required by 37 C.F.R. 1.111(b) and respectfully request that 
Examiner continue with her examination of the amended claims as provided by 37 C.F.R. 

20 1.111(a). No fees are believed to be required for this response. Should any be, please 
charge them to deposit account number 501315. Applicant's Attomey would like to 
close by thanking Examiner and her SPE Susanna Diaz both for granting for the 
interview and making it such a pleasure. 

25 Respectfully submitted. 




Attomey of record, 
Gordon E. Nelson 
57 Central St., P.O. Box 782 
Rowley, MA, 01969, 
Registration number 30,093 
Voice: (978)948-7632 
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